Dreams A distributed framework for synchronous coordination

Behaviour Types The original semantics of Reo is defined in terms of abstract behaviour types [8], which are co-inductively defined relations over timed data streams (a timed stream paired with a value stream). These models account for synchronisation, dataflow, and, implicitly, state changes. They mention neither context dependency nor reconfiguration. This semantics provide little guidance for implementing Reo, so we do not consider it further. Automata-based Models Various automata-based models for Reo exist. We consider the following four: constraint automata (CA) [20], intensional constraint automata (ICA) [37], port automata (PA) [67], and Reo automata (RA) [27]. These models provide the semantics of each Reo primitive and their composition, by representing the synchronisation possible in a connector and possibly a description of the dataflow in the transitions of the automata. In all of these models synchronisation is represented by a set of ports in each transition, and the dataflow by constraints. CA is the only automata model of Reo that captures data, as the other models focus on different issues. PA were devised to study decomposition of automata, and hence they capture only synchronisation and state. Neither CA nor PA have context dependency, so they can only express a variant of LossySync which makes a non-deterministic choice between passing the data onwards and losing it. Context dependency was later incorporated in an automata model, firstly in ICA, by reverse engineering ideas from connector colouring, and, subsequently and more compactly, in RA. 142 CHAPTER 5. CONSTRAINT-BASED MODELS FOR REO Reconfiguration in the presence of an automaton-based model requires both maintaining a description of the connector and completely re-computing the underlying semantics of a connector whenever reconfiguration occurs [34]. Additional variants of constraint automata proposed asReo models include notions of time [13], quality-of-service guarantees [15], resource bounds [75], or probability [21]. Connector Colouring Connector colouring [31] is based on the simple idea that ports in a connector where data flow and where data does not flow can be coloured with different colours (see §5.5). Each primitive has a set of colourings describing its possible behaviours. The semantics of a connector is determined by plugging together the colourings of the primitives in such a way that the colours match, meaning that dataflow either occurs or does not occur at the node. Connector colouring follows the shape of the connector, and computes all possible behaviours for the given step. Two variants of connector colouring exist. The first, called 2-colouring (CC2), has one colour representing dataflow and one representing no dataflow. The second, called 3-colouring (CC3), splits the no dataflow colour into two to capture context, as described in §5.5. CC2 captures only synchronisation, whereas CC3 captures both synchronisation and context dependency. Both connector colouring schemes abstract away from the data passed and state transition, but this information can be added in implementations, as long as the value of the data does not affect synchronisation and it is not transformed. As connector colouring is computed on-the-fly, reconfiguration has no impact on the computation of connector semantics, as the most recent version of the connector is used to compute the colouring table. SOS Mousavi et al. present a structural operational semantics (SOS) formalisation of Reo using Maude [82]. Two versions of the semantics were developed: the original formulation (SOS) and an extension with a notion of maximal flow to capture a notion of context dependency (SOS+FLOW), which is not as flexible as the corresponding notion enforced by 3-colouring. Khosravi et al. further explore this idea using Alloy [64]. One advantage of the SOS approach is that it deals with causality issues in connectors (which we deliberately ignore, as most other models of Reo do). Clarke [33] explores causality in depth, presenting Reo semantics in terms of the proof theory of intuitionistic linear logic and zero-safe Petri nets. These approaches do not consider reconfiguration. An alternative operational semantics is based on the Tile Model [50, 14]. Tiles can be composed in three different ways to generate proof steps: hori5.9. COMPARISON OF REO MODELS 143 zontally, vertically, or in parallel. Horizontal composition represents synchronisation, and can be performed only when the effect of one tile matches the trigger for another tile. Vertical composition represents changes of the system in time, requiring that the final configuration of one tile matches the initial configuration of another tile. Finally, parallel composition represents concurrent execution of tiles. This approach extends connector colouring (both 2and 3-colouring) to include data, state and a primitive notion of reconfiguration (though not causality). As such, the tile models (TILE2 and TILE3) are two of the most complete semantic descriptions of Reo. Constraint-based Approach Our constraint approach deals with synchronisation, data awareness, state, and context dependency in an orthogonal and uniform way. We defined different constraints for each of these notions, which are then added conjunctively to capture any combination of them (along with certain axioms connecting the various kinds of variables). Beyond the other models, constraints can be used to express that multiple inputs are available on a particular node, whereas other models deal only with a single datum (or do not mention data at all). Reconfiguration was not considered for the model presented in this chapter, though it would be implemented by rewriting the appropriate constraints. Table 5.10 presents a comparison of the various approaches along four dimensions of interest (all models express synchronisation). Only three of the models receive three Xs, namely SOS+FLOW, TILE3, and Constraints. SOS+FLOW was not considered for implementation as the notion of maximal flow is not as flexible as the notion of context dependency enforced by 3colouring. As TILE3 extends the 3-colouring model to include data awareness and state, and we have shown how to encode synchronisation, data awareness, state, and 3-colouring style context dependency into constraints, we conclude that these are semantically comparable approaches. 5.9.2 Reo Engines The coordination abstractions provided by Reo impose some implementation challenges, so most approaches to implementing Reo involve directly implementing some semantic model. Each semantic model induces different characteristics and limitations on implementations based on it. We now compare existing and possible implementations ofReo on the implementation approach, on the numbers of solutions computed, and on whether the behaviour is precomputed. 144 CHAPTER 5. CONSTRAINT-BASED MODELS FOR REO Model Data Awareness State Context Dependency Reconfiguration ABT X X 7 None CA X X 7 Re-compute ICA 7 X X Re-compute PA 7 X 7 Re-compute RA 7 X X Re-compute CC2 7 7 7 Compatible CC3 7 7 X Compatible SOS X X 7 Compatible SOS+FLOW X X X Compatible TILE2 X X 7 Some TILE3 X X X Some Constraints X X X Compatible Figure 5.10: Comparison of Reo models. None means that reconfiguration is unfeasible. Re-compute means that reconfiguration would require recomputing the entire semantics. Compatible means that the model is compatible with reconfiguration, because semantics are computed on-the-fly. Some means that the model has some notion of reconfiguration built in. implementation approach The approaches we cover include a speculative approach, compilation into automata, connector colouring, a searchbased approach, and constraint solving. number of solutions computed when determining what to do in the next step, two approaches are possible: 1. (all-sol) find all possibilities for a round, and choose one of them non-deterministically (or based on some other scheme); and 2. (one-sol) find only some (typically one) of the possible solutions. pre-computed behaviour when computing the behaviour of a connector, two approaches are possible: 1. (all-steps) pre-compute all future behaviour a priori ; and 2. (single-step) compute the behaviour of a single step at a time. Speculative Approach This approach to implementing Reo consists of speculatively trying to send data through channels and rolling back when an 5.9. COMPARISON OF REO MODELS 145 inconsistency arises. Had such an approach been successfully implemented, it would have computed one solution at a time (one-sol) for a single step (singlestep). This is all speculation, however, as this approach was never successfully implemented due to the inherent impossibility of locally making the globally consistent choices, and the difficulty of managing distributed rollback and subsequent retries. Automata-based Implementations This approach to implementing Reo compiles the behaviour of a connector into an automaton [73], and thus precomputes all future behaviour at compile-time (all-steps, all-sol). Implementations of all-steps semantics do not scale, since finding all possible behaviour for all possible states of a concurrent system is very expensive and space inefficient. For example, the number of states generally doubles for every FIFO1 buffer in a connector, assuming all states are reachable. Certainly, infinite state spaces are excluded. Furthermore, implementations based on automata models are inherently centralised, and lose all potential parallelism, as a connector is implemented using a single automaton. On the other hand, this means that they can be efficient at run-time, though they need to be re-computed when reconfiguration occurs. They trade off run-time efficiency for flexibility. Connector colouring-based implementations These implementations encode the behaviour of the next step of a connector as a colouring table and compose the colouring tables using a notion of matching, as described above in §5.5. Implementations based on this approach compute all solutions (all-sol) for a single step (single-step). The disadvantage of computing all steps is the overhead of computing choices that are not used. Reolite [31] was the first prototype implementation based on connector colouring. A more recent and efficient engine is incorporated into the Reo toolset [9]. The latter version was used as a comparison in our benchmarking. Connector colouring also forms the basis of our upcoming distributed implementation, which we discuss below in §5.9.3. Search-based Implementation These include implementations based on the SOS models and, hypothetically, on the Tile models. The Maude implementation of SOS [82] could find a single solution (one-sol), whereas the implementation of SOS+FLOW [82] computed all possibilities (all-sol), which were then ordered based on a maximal flow test. The result was extremely inefficient, although the encoding of SOS+FLOW in Alloy [64] potentially offers a better one-sol-implementation technique using SAT solving. Unfortunately, no benchmarks were presented in that paper, and as the implementation is 146 CHAPTER 5. CONSTRAINT-BASED MODELS FOR REO very much a prototype, we have not included it here for comparison. TILE2 and TILE3 could easily be implemented in a similar fashion using Maude, though this has not been done, as far as we are aware. 〈〈to Erik: you ask if I expect better performance than SOS+FLOW. Hard to say: I would say equivalent. Implementations based on SAT solving can be more efficient in both cases.〉〉 Constraint Satisfaction The implementation approach described in this chapter is based on constraint satisfaction techniques to derive efficient executable implementations of Reo. The constraints are solved per round (singlestep) and use the heuristics of the constraint solver to stop the search for solutions once a single solution is found, avoiding exploring the full solution space (one-sol). We summarise the classification of implementation approaches discussed in this section in Table 5.8. Implementation Approach Number of Solutions Pre-computed Behaviour Speculative approach one single Compilation into automata all all Connector colouring all single Search-based one single Constraint satisfaction one single Table 5.8: Classification of Reo implementations approaches. 5.9.3 Constraints in Dreams The distributed framework Dreams, the main contribution of this thesis, described in the next chapter, started to be developed prior to our constraintbased approach for coordination. Dreams executes Reo connectors in a distributed environment, and restricts communication so that it can occur only through primitives, and thereby prohibiting both a global agent and direct node-to-node communication. This restriction imposes additional obligations on the implementation of primitives. Specifically, it requires them to play a significant role in the global constraint resolution process, for instance, to pass around colouring tables and to serve as the conduits for all “coordination communication,” as well as for normal communication. 5.10. RELATED WORK 147 In the distributed implementation the primitives follow a distributed protocol to achieve consensus regarding how data should flow in each round, and only then data is passed through the primitives. The initial implementation of Dreams relied on connector colouring, but now we incorporated the constraintsolving techniques described in this section to improve efficiency. The Dreams framework and its implementation will be described in Chapters 6 and 7, respectively.